The release-homebrew workflow previously delegated checksum computation
to the third-party action `mjcheetham/asset-hash`, which downloads the
release asset and hashes the bytes locally. GitHub has been observed to
occasionally serve an HTML error page (the "unicorn" page) with a 200
status code in place of release-asset content. When that happens the
local hash succeeds against the wrong bytes and an incorrect SHA-256
ends up in the Cask, which then prevents users from installing.

This is exactly what happened with v2.54.0.vfs.0.2, reported in
microsoft/homebrew-git#102: the recorded checksum hashed the unicorn
page (8e8052a0...) rather than the `.pkg` (983dd1b1...).

The GitHub Releases API itself reports the asset's SHA-256 in the
`digest` field of every asset entry, computed server-side when the
asset is uploaded. Read that value directly instead of recomputing
locally, so a corrupted download can no longer poison the checksum.

The replacement step uses `gh api` (already available on
ubuntu-latest) and emits collapsible log groups with the release
metadata, the full asset list (name, size, digest), and the full
selected-asset record. If the API ever returns something bogus
again, the workflow run will contain everything needed to diagnose
it without re-running the release.

Asset selection mirrors the previous regex (`git-(.*)\.pkg`); the
step fails fast if zero or multiple assets match, or if the digest
is missing, non-sha256, or not a 64-character hex string.

Assisted-by: Claude Opus 4.7
Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com>